<html>   
<head>
<meta http-equiv="content-type" content="text/sgml;charset=utf-8" >
<style type="text/css">
body {background: white;color: black}
h1 {color: #c33;background: none;font-weight: bold;text-align: center}
h2 {color: #00008b;background: none;font-weight: bold}
h3 {color: #006400;background: none;margin-left: 4%;margin-right: 4%;font-weight: bold}
h4 {margin-left: 8%;margin-right: 8%;font-weight: bold}
h5 {margin-left: 6%;margin-right: 6%;font-weight: bold}
div {margin-left: 10%;margin-right: 10%;}
ul, ol, dl, p {margin-left: 6%;margin-right: 6%}
pre {font-family: monospace; margin-left: 5%;white-space: pre}
</style>

<title>ARDOP Serial Interface Protocol.</title>
</head>

<body bgcolor="#ffffff" text="#000000" link="#0000ff" vlink="#800080" alink="#ff0000">
<h1>ARDOP Serial Interface Protocol.</h1>

<h2>Overview.</h2>
<p>
 The Host to TNC protocol used over Serisl and Bluetooth links operates in two modes, Text or Hostmode. 
 Text mode is primarily used for initialisation and testing, but can be used for simple interative
 QSO's using a standard ASCII terminal program. There is no error checking on the text interface.
 Hostmode is used for automatic operation, and provides error detection and recovery over the 
 serial/Bluetooth line. ARDOP Hostmode is based on the SCS CRC Hostmode (as used in 
 the PTC and Dragon Controllers) which is itself an extension of WA8DED Hostmode.
 
<h2>Operating Modes.</h2>
<p>
 Either Protocol Mode can be used on one of two Operating Modes. ARDOP Native or PTC Emulation.
 The former supports the full ARDOP functionality, the latter enables ARDOP to be used with programs
 that support an SCS Pactor controllet, but don't have native ARDOP support.

<h3>ARDOP Native Mode.</h3> 
<p>
 ARDOP Native Mode is designed to be functionally similar to the TCP mode, to simplify host
 program and TNC support. Two DED Channels are assigned to the functions of the two TCP ports,
 Channel 32 for Control and Channel 33 for Data. A third channel (34) is used for debug information,
 as a standalone TNC doesn't usually have local storage for writing a debug log. The Protocol control channels
 (255 for polling, 254 for status and 253 for rig control) are used as defined by SCS.
 
<h3>PTC Emulation Mode.</h3>
<p>
This supports basic ARQ mode operation with software designed for Pactor. FEC operation isn't
supported, but the Pactor Levels 1-4 are mapped to the ARDOP Bandwidths of 200 to 2000. Pactor
Host Mode commands are converted to equivalent ARDOP commands, and ARDOP link status values mapped 
to equivalent Pactor values.

 <h2>Protocol Overview</h2>
 <p>
  The protocol is polled master/slave, with a single bit sequence toggle to detect lost or duplicated frames.
 The host program is the master and the TNC the slave. The polling frequency isn't defined, but a maximum interval of 100mS is recommended to minimise latency.
 <br><br>
 The link is considered Idle when the master has received an in-sequence response to its previous transmission.
 The master can transmit at any time the link is idle. If it has data to send, it sends it, otherwise it sends a 
 General Poll message. The slave will respond with a list (possibly empty) of channels with data available. The master then polls each channel in the list.
 <br><br>
 If the master doesn't receive a valid response from the slave in a resonable time, it will repeat its last transmission. It it doesn't get a reponse after a reasonable number of retries it will report a link failure to 
 the higher lovel software, which will abort any transmission n progess, then try to reestablish the link.
 <br>
 <br>
 If the master receives an out of sequence response following a timeout and retry it will assume a delayed response 
 from the slave, discard the respeat, and continue to wait for a valid frame. If it receives an out of sequence response at any other time it will assume a protocol error and reset and restart the link.
 <br>
 <br>
 If the slave receives an out of sequence message it will assume that its previous response was lost, discard the message and resend the previous response unchanged.
 
 

 <h2>Packet Formats</h2>
 
  <pre>
 
 All packets have a two byte header of 0xAAAA and a two byte CRC-16 checksum on end
 The top bit of the Opcode field is a sequence toggle.
 
 The basic packet format is:
 -----------------------------------------------
 |Header|Chan|Opcode| Payload          | CRC |
 -----------------------------------------------
 |AA AA | XX |  XX  | XX XX XX .... XX |XX XX|
 -----------------------------------------------
 
 Payload can have two formats, either a Null terminated ASCII string or a Byte Count of
 0 to 255 followed by 1 to 256 bytes of data. 
 
 There are two opcodes for Host to TNC packets, and eight for TNC to Host, though not
 all are used in ARDOP Native Mode.
 
 From Host to TNC
 
 Opcode 0 - Data
 Opcode 1 - Command
 
 From TNC to Host
 
 Opcode 0 - Response Success (no data follows)
 Opcode 1 - Response Success, followed by null terminated message
 Opcode 2 - Response Failure, followed by null terminated message
 Opcode 7 - Data, preceeded by (length-1)
 
 Channel 32 is used for Commands, Channel 33 for Data and Channel 34 for Debug information. Typical messages 
 are shown below (control fields in Hex). Note that the Command format is used for hostmode 
 protocol level commands. ARDOP commands (such as "ARQCALL") are sent as data on the 
 Command channel. The Debug channel is for information to be written to a debug log.
 
 General Poll
 
 ----------------------------------
 |Header|Chan|Opcode|Payload| CRC |
 ----------------------------------
 |AA AA | FF |  01  | 00 47 |XX XX|
 ----------------------------------
 
 Response is a null terminated list of channels with available data. Value is Channel plus 1
 
----------------------------------
 |AA AA | FF |  01  | 21 00 |XX XX|            Channel 32 has data (0x21 = 32 + 1)
 ----------------------------------
  
 Poll to TNC Command Channel
 
 ----------------------------------
 |Header|Chan|Opcode|Payload| CRC |
 ----------------------------------
 |AA AA | 20 |  01  | 00 47 |XX XX|
 ----------------------------------
 
 Response is an async ARDOP response message
 
 --------------------------------------------------
 |Header|Chan|Opcode| Payload               | CRC |
 --------------------------------------------------
 |AA AA | 20 |  07  |<0F>c:NEWSTATE ISS <0D>|XX XX|
 --------------------------------------------------
 

 ARDOP Command to TNC
 -----------------------------------------------------
 |Header|Chan|Opcode| Payload                  | CRC |
 -----------------------------------------------------
 |AA AA | 20 |  00  |C:MYCALL G8BPQ <00>       |XX XX|
 ----------------------------------------------------
 response
 -----------------------------------------------------
 |AA AA | 20 |  01  |c:MYCALL now G8BPQ <00>   |XX XX|
 -----------------------------------------------------
 
 Data to be transmitted
 -----------------------------------------------------
 |Header|Chan|Opcode| Payload                  | CRC |
 -----------------------------------------------------
 |AA AA | 21 |  00  |<12>D:(Len)Message to Send|XX XX|
 -----------------------------------------------------
 response
 -----------------------------------------------------
 |AA AA | 21 |  00 |                           |XX XX|
 -----------------------------------------------------
 
 Received Data from TNC
 
 Data to be transmitted
 -----------------------------------------------------
 |Header|Chan|Opcode| Payload                  | CRC |
 -----------------------------------------------------
 |AA AA | 21 |  07  |<13>d:(Len)ARQMsg Received|XX XX|
 -----------------------------------------------------
 This is no response to inbound frames, apart from the implied ACK of the
 next host frame having an inverted toggle.
 
 
 </pre>
 
<h2>Appendix</h2> 
<p>
 <b>SCS CRC Hostmode</b><br><br>
 
 See the PTC-IIIusb Manual Chapter 10 for details of CRC Hostmode .<br><br>
 
 <b>WA8DED Packet Format</b><br><br>
 
 There are two data formats, null terminted or counted.
 
<pre>
 
 Byte 0		Channel Number
 byte 1		Type Code (see table below)
 byte 3-end	Null Terminated string (max length 255)
 or
 byte 3		Info Length - 1
 byte 4-end Info (length 1 to 256)

SCS CRC Hostmode adds two byte of 170 to the front and a crc-16 checksum to the end.
It also defines the top bit (bit 7) of the Type Code as a sequence toggle and next bit
(bit 6) as a sequence reset flag. Data transparency is ensured by adding a null byte
after any occurence of 170 in the message or crc. 

Command Codes

		  Host to Tnc
          -----------
 CHANNEL   CODE           DESCRIPTION
 -------   ----           -----------
    n       0        Information (preceeded by length-1)
    n       1        Command     (preceeded by length-1)

          Tnc to Host
          -----------
 CHANNEL   CODE           DESCRIPTION
 -------   ----           -----------
    n       0        Success (nothing follows)
    n       1        Success (message follows, null terminated)
    n       2        Failure (message follows, null terminated)
    n       3        Link Status (null terminated)
    n       4        Monitor Header (null terminated)
    n       5        Monitor Header (null terminated)
    n       6        Monitor Information (preceeded by length-1)
    n       7        Connect Information (preceeded by length-1)
</pre>
</html>